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Prufungsantrag gem. § 44 PatG 1st gestellt 

@ Medizinische Systemarchitektur, basierend auf Microsoft OLE/OCX und Automation, bzw. Atomic 

@ Die Erfindung betrtfft eina medizinische Systemarchitektur 
mit einer Modalitat (1 bis 4) zur Erfassung von Bildern, einer 
Von-ichtung (S bis 8, 11. 12) zur Verarbeitung der Bilder und 
einer Vorrichtung (9) zur Obertragung der Bilder, bei dem die 
Vorrichtung (5 bis 8, 11. 12} zur Verarbeitung ein digitales 
Bildsystem mit ainem Rechner aufweist, der nach einem 
Verfahren zum Datenauttausch zwischen varschiedenen 
Anwendungsprogrammen (OLE) mit grafischen Stauerete- 
menten und einem Standard fur OLE Custom Controls (OCX) 
arbeitet, wobel jedem oinzelnen durch Gronzen limitierten 
ProzeS ein OCX-Software-Baustein (18) zugeordnet ist der 
mit einem OLE-Automation- oder ATOMIC-Femsteuerbau- 
stein (19. 22, 27 bis 31, 35 bis 41) enA/eitert sind. damit die 
Vorrichtungen und Prozesse fernsteuerbar und die Limitier- 
ungen aufgehoben sind. 
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Beschreibung 

Die Erfindung betrifft eine medizinische Systemarchi- 
tektur mit einer Modalitat zur Erfassung von Bildem, 
einer Vorrichtung zur Verarbeitung der Bilder und einer 
Vorrichtung zur Obertragung der Bilder, bei dem die 
Vorrichtung zur Verarbeitung ein digitales Bildsystem 
mit einem Rechner aufweist, der nach einem Verfahren 
zum Datenaustausch zwischen verschiedenen Anwen- 
dungsprogrammen (OLE) mit grafischen Steuerelemen- 
ten und einem Standard fur OLE Custom Controls 
(OCX) arbeitet, wobei jedem einzelnen durch Grenzen 
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mus zur Ausbreitung eines Ereignisses (Event Propaga- 
tion Mechanismus) dient, sobald Rechner-dezentrali- 
siertes OLE erhaitlich ist, um ein realistisches auf einer 
Systemarchitektur basierendes Model- View-Controller 
5 Konzept(MVC)zuerhalten. 

Auch kann erfmdungsgemaB Microsoft OCX zur Er- 
stellung von Komponenten fur grafische Benutzerober- 
flachen (Graphical User Interface (GUI) Components) 
innerhalb eines Microsoft-Container-ProzeB verwendet 
10 werden. Dadurch erhalt man wirkiich binarkompatible, 
wiederverwendbare GUI- Komponenten. 

Weiterhin laBt sich erfindungsgemaB Microsoft OCX 



iimitierten Frozeb em OCX-Software-Baustein zuge- mit OLE-Automation oder mit Software-IC-Verbindun- 

ordnet ist gen zur verteilten Ausbreitimg eines Ereignisses (Event 

Medizinische Systeme werden immer komplexer, 15 propagation) mit lokaler Optimierung mit der Kontroll- 

wahrend der Erweiterungsgrad medizinischer Systeme ebene und auch zwischen der Kontrollebene und der 

itn gleichen Verhaltnis anwachst Dadurch wird jedoch Serviceebene kombinieren. Dies gibt die Flexibilitat zur 

eine sehr flexible Architektur benotigt moglichen Verbreitung von Komponenten mit binar- 

Die bisher bekannten Architekturen sind im wesentli- kompatiblen Interface, basierend auf Shared Libraries, 

chen ohne dezentraler Software und Software-Baustei- 20 Dadurch erhalt man nicht GUI-abhangige und verteil- 

nen entworfen worden. bare Objekte. 

Weiterhm verhmdert der einfache Einsatz von Class- Diese Naherung ermoglicht es, Prozesse nicht durch 

Bibliotheken trotz des Gebrauches von Objekt-Orienta- Design, sondem hauptsachlich durch Konfiguration von 

tion die Konstruktion von flexiblen und wiederver- gemeinsam genutzten Programmkomponenten (Shared 

wendbaren Komponenten, da Classes in WirkUchkeit in 25 Libraries (DLLs)) zu erstellen. 

groBemMaBe nicht richtigwiederverwendbar sind Die Erfindung ist nachfolgend anhand von in der 

Die Erfindung geht von der Aufgabe aus, Software- Zeichnung dargestellten Ausfuhrungsbeispielen naher 

Bausteine (Objekte) zu konstruieren, die ein Verhalten erlautert Es zeigen: 

aufweisen, das sich mdglichst selbst tragt Weiterhin Fig. 1 ein vernetztes Datenbanksystem gemaB dem 

soUten die Verbindungen zwischen den Bausteinen im 30 Stand der Technik, 

Verhaltnis zum Ort dieser Bausteine (Objekte) unsicht- Fig. 2 bis 5 eine Darstellung zur Eriauterung der er- 

bar sein, so daB sie entweder alle in einem ProzeB verei- findungsgemaBen Zusammenarbeit der Software-Bau- 

nigt Oder uber ein Netzwerk verteilt sein konnen. steine nach einem ersten Ausf uhrungsbeispiel und 

Die Aufgabe wird erfhidungsgemaB dadurch gelost, Fig. 6 eine Darstellung zur Erlauterung der erfm- 

daB die Systemarchitektur derart ausgebildet ist, daS die 35 dungsgemaBen Zusammenarbeit der Sof tware-Baustei- 

OCX-Software-Bausteine mit einem Femsteuerbau- ne nach einem zweiten AusfiihnmgsbeispieL 

stein erweitert sind, damit die Vorrichtungen und Pro- In Fig. 1 ist die Systemarchitektur eines medizini- 

zesse femsteuerbar und die Limitierungen aufgehoben schen Computemetzwerkes dargestellt Zur Erfassung 

sind. Durch die Kombination von Software-Bausteinen medizinischer Bilder dienen die Modalitaten 1 bis 4, die 

(Objekten) und flexibel verteilten Ereignismechanismen 40 als bilderzeugende Systeme beispielsweise eine CT-Ein- 

ergibt sich eine gute Ldsung dieser Aufgabe. heit 1 fur Computertomographie, eine MR-Einheit 2 fiir 

Es hat sich als vorteilhaft erwiesen, wenn der Fern- Magnetische Resonanz, eine DSA-Einheit 3 fur digitale 

steuerbaustein ein OLE-Automation-Interface ist und Subtraktionsangiographie und eine Rontgeneinheit 4 

die Fernsteuerung nach dem OLE-Automation Stan- fur die digitale Radiographie 4 aufweisen kann. An diese 

dard erfolgt Erf indungsgemaB kann der Femsteuerbau- 45 Modalitaten 1 bis 4 kdnnen Workstations 5 bis 8 ange- 

stein ein Automation Interface Baustein ist schlossen sein, mit denen die Modalitaten 1 bis 4 gesteu- 

Eine alternative vorteilhafte Losung ergibt sich, wenn ert und die erfaBten medizinischen Bilder verarbeitet 

die Fernsteuerung mit Software-IC-Verbmdungen bei- und abgespeichert werden konnen. Eine derartige 

spielsweise nach dem ATOMIC-Standard erfolgt Erfin- Workstation ist beispielsweise ein sehr schneller Klein- 

dungsgemSB kann in diesem Falle der Femsteuerbau- 50 computer auf der Basis eines oder mehrerer schneller 

stein ein Connectable/Remote Interface Baustein ist Prozessoren. 

Es hat sich als vorteilhaft erwiesen, wenn das Verf ah- Die Workstations 5 bis 8 sind mit einem BUdkommu- 

ren zum Datenaustausch der Microsoftstandard OLE nikationsnetz 9 zur Verteilung der erzeugten Bilder und 

und der Standard fiir OLE Custom Controls der Micro- Kommunikation verbunden. So konnen beispielsweise 

softstandard OCX ist, 55 die ui den Modalitaten 1 bis 4 erzeugten Bilder in einem 

ErfindungsgemaB kann die medizinische Systemar- zentralen Bildspeicher 10 abgespeichert oder an andere 

chitektur Microsoft OCX zur Erstellung von Kompo- Workstations 5 bis 8 weit ergeleitet werden. 

nenten fur grafische Benutzeroberflacheh innerhalb ei- An dem Bildkommunikationsnetz 9 konnen weitere 

nes Microsoft-Container-ProzeB verwenden, wobei Mi- Workstations als Befimdungskonsolen 11 und 12 ange- 

crosoft OCX mit OLE-Automation oder mit Software- eo schlossen sein, die mit einem lokalen Bildspeicher 13 und 

ICs (Atomic) zur verteilten Ausbreitung eines Ereignis- 14, beispielsweise einer Jukebox, verbunden sein kon- 

ses mit der Kontrollebene tmd zwischen der Kontroll- nen. In den Befundungskonsolen 11 und 12 konnen die 

ebene und der Serviceebene kombiniert werden kann. erfaBten und im Bildspeicher 10 abgelegten Bilder nach- 

Das wichtige neue Merkmal ist die Kombination von traglich zur Befimdung abgerufen imd in dem lokalen 

Microsoft OLE Custom Controls (OCX), einer neu ent- 65 Bildspeicher 13 und 14 abgelegt werden, von dem sie 

standenen Software-Technologie, mit einem anderen unmittelbar der an der Befundungskonsole 11 oder 12 

generellen Microsoft-Scripting-Standard Interface, das arbeitenden Befundungsperson zur Verfugimg stehen 

als voU verteilungsfahiger netzwerkweiter Mechanis- konnen. 
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Der Bild- und Datenaustausch uber das Bildkommu- 
nikationsnetz 9 kann dabei nach dem DICOM-Standard 
erfoJgen, einem Industriestandard zur Obertragung von 
Biidern und weiteren medizinischen Informationen zwi- 
schen Computern zur Ermoglichung der digitalen Kom- 5 
munikation zwischen Diagnose- und Theraphiegeraten 
unterschiedlicher Hersteller. An dem Bildkommunika- 
tionsnetz 9 kann ein Netzwerk-Interface 15 angeschlos- 
sen sein, iiber das das interne Bildkommunikationsnetz 9 
mit einem globalen Datennetz verbunden ist, so daB die 10 
standardisierten Daten mit unterschiedlichen Netzwer- 
ken weltweit ausgetauscht werden konnen. 

In der Fig. 2 ist ein erstes Beispiel einer Software- Ar- 
chitektur nach dem MVC-Konzept (Model- View-Cont- 
roller) dargestellt, bei dem die Bausteine View, Control 15 
und Model jeweils in einem ProzeB enthalten sind. In 
einer dynamischen Link-Bibliothek (DLL) eines In-Pro- 
cess Server 16, befindet sich der View-Bereich. 

Eine dynamischen Link-Bibliothek (dynamic link li- 
brary) ist eine Sammlung von Objektfiles, die zur Lauf- 20 
zeit (dynamisch) eines Prozesses diesem hinzugelinked 
(verfugbar gemacht) und von mehreren Prozessen 
gleichzeitig genutzt werden kann. Beim In-Process Ser- 
ver 16 ist die Implementierung eines Services derart 
realisiert, daB dieser Service immer im selben ProzeB 25 
ablaufen muB wie der Kunde (client), der diesen Service 
benotigt Hierzu eignen sich insbesondere DLLs, da sie 
den Service dem ProzeB dynamisch bei Bedarf zur Ver- 
fugung stellen. 

In dem Server 16 ist das Anwendimgsprogramm 17 30 
geladen, das mehrere OCX-Software-Bausteine 18 auf- 
weist An den OCX-Bausteinen 18 sind als Femsteuer- 
bausteine Automation Interface Bausteine 19 des OLE- 
Automation Standards angekoppelt Aufgrund dieser 
Bausteine wird es ermoglicht, mit anderen lokalen Ser- 35 
vern zu kommunizieren. So kann in einem zweiten loka- 
len Server 20 ein Controller 21 zur Kopplung der View- 
Ebene mit der Model-Ebene gespeichert sein. Dieser 
Controller 21 ist ebenfalls mit einem entsprechenden 
Automation Interface Baustein 22 gekoppelt 40 

Der Controller 21 eine Komponente aus der Model- 
View-Controller (MVC) Welt Dabei reprasentiert 'der 
View eine Sichtweise auf das Model. Model und View 
sind uber eine Controller Komponente gekoppelt Diese 
Controller Komponente besteht zu wesentlichen Teilen 45 
aus einem Zustandsautomaten, einer sogenannten Fini- 
te State Machine (FSM). 

Die Model Komponente kann in zwei weiteren loka- 
len Servem 23 und 24 enthalten sein, in denen die Servi- 
ce-Bausteine 25 und 26 uber weitere Automation Inter- 50 
face Bausteine 27 bis 31 miteinander gekoppelt sind. 

In den Fig. 3 bis 5 ist der Aufbau im wesentlichen der 
gleiche, lediglich die ProzeBaufteilung ist anders. Wah- 
rend im ersten Fall gem^B Fig, 2 alle MVC-Bausteine in 
jeweils einem getrennten ProzeB angeordnet sind, sind 55 
beim Beispiel gemaB Fig. 3 die Bausteine View und 
Control in einem ProzeB und die Model-Bausteine in 
getrennten Prozessen angeordnet. Das bedeutet, daB 
sich die Kontrollebene des Controllers 21 bereits in der 
gleichen dynamischen Link-Bibliothek (DLL) eines In- eo 
Process-Servers 32 wie das Anwendimgsprogramm 17 
der View-Komponente befindet 

Beim Gegenstand gemaB Fig. 4 sind die Bausteine 
Control und Model in einem ProzeB zusammengefaBt 
und befinden sich in der gleichen dynamischen Link-Bi- 65 
bliothek (DLL) des lokalen Servers 33. Erfindungsge- 
mSB besteht auch die Moglichkeit, die Bausteine View, 
Control und Model gemaB Fig. 5 in einem ProzeB in der 



dynamischen Link-Bibliothek (DLL) eines In-Process- 
Servers 34 zu vereinen, wobei ein weiterer Service-Bau- 
stein in einem weiteren lokalen Server 24 enthalten ist 

In der Fig. 6 ist ein zweites Beispiel nach dem MVC- 
Konzept (Model View Controller) dargestellt, das dem 
Beispiel gemaB Fig. 2 ahnlicfa ist Auch hier befmdet sich 
der View-Bereich wiederum in einer dynamischen Link- 
Bibliothek (DLL) des In-Process-Servers 16. An den 
OCX-Software-Bausteinen 18 des in dem Server 16 ge- 
ladenen Anwendungsprogramm 17 sind sogenannte 
Software-IC-Verbindungen 35 (Connectable/Remote) 
als Femsteuerbausteine anstelle der Automation Inter- 
face Bausteine 19 angekoppelt Mittels dieser Bausteine 
wird die Kommunikation mit anderen lokalen Servem . 
20, 23 und 24 ermoglicht So kann in dem lokalen Server 
20 der Controller 21 zur Kopplung der View-Kompo- 
nente mit der Model- Komponente sein. Dieser Control- 
ler ist ebenfalls mit entsprechenden Software-IC-Ver- 
bindungen 36 und 37 gekoppelt Die Model-Komponen- 
te ist in den lokalen Servem 23 und 24 angeordnet, in 
denen uber weitere Software-IC-Verbindungen 38 bis 
41 die Service-Bausteine 25 und 26 enthalten sind. 

Diese Connectable/Remote-Software-IC Femsteuer- 
bausteine sind voU-verteilimgsfahige Eingangs/Aus- 
gangs-Ereignisse, basierend auf ein Ereignis kommuni- 
zierendes Netzwerk, daB dynamisch linkbar und durch 
Eingangs/Ausgangs-Verbindungspimkte konfigurierbar 
ist 

Der Vorteil dieses erfindungsgemSBen Vorschlages 
liegt in seiner Flexibilitat und noch mehr in seiner Pro- 
duktivitat zur Erlangung von in verschiedenen medizini- 
schen Systemproduktarchitekturen wiederverwendba- 
ren Software-Bausteinen. 

Die Software-IC-Verbindungen erlauben eine wirkli- 
che beliebige Verteilung der Komponenten in ablauffa- 
higen Prozessen ohne in Verklenmiungszustande zu ge- 
raten, wie dies bei anderen Kommunikationsmechanis- 
men (z. B. Corba) der Fall sein kann, ohne Quellcode- 
Anderung. Die Komponenten konnen dadurch sogar 
zur Laufzeit belie big kombiniert werden. Ein weiterer 
Vorteil ist, daB die Verbindungen n:m Verbindungen 
sein konnen, was bei herkominiichen Systemen meist 
nicht moglich ist, wobei sich die Verbindungspartner 
anonym zur Laufzeit findea 

Zusatzlich unterscheiden sich die Komponentenver- 
bindungen von herkommlichen auch dadurch, daB auf 
den Verbindungen Ereignis-Daten flbertragen werden 
und keine entfernten Methoden gerufen werden. 

Patentanspriiche 

1. Medizinische Systemarchitektur mit einer Moda- 
litat (1 bis 4) zur Erfassung von Biidern, einer Vor- 
richtimg (5 bis 8, 1 1, 12) zur Verarbeitung der Bilder 
und einer Vorrichtung (9) zur Obertragung der Bil- 
der, bei dem die Vorrichtung (5 bis 8, 11, 12) zur 
Verarbeitung ein digitales Bildsystem mit einem 
Rechner aufweist, der nach einem Verfahren zum 
Datenaustausch zwischen verschiedenen Anwen- 
dungsprogranunen (OLE) mit grafischen Steuerele- 
menten und einem Standard fiir OLE Custom Con- 
trols (OCX) arbeitet, wobei jedem einzehien durch 
Grenzen limitierten ProzeB ein OCX-Software- 
Baustein (18) zugeordnet ist, dadurch gekenn- 
zeichnet, daB die Systemarchitektur derart ausge- 
bildet ist, daB die OCX-Software-Bausteine (18) mit 
einem Ferasteuerbaustein (19, 22. 27 bis 31, 35 bis 
41) erweiten sind, damit die Vorrichtungen und 
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Prozesse fernsteuerbar und die Limitierungen auf- 
gehoben sind. 

2. Medizinische Systemarchitektur nach Anspruch 
1, dadurch gekennzeichnet^ daB der Fernsteuerbau- 
stein ein OLE-Automation- Interface (19, 22, 27 bis 
31)ist 

3. Medizinische Systemarchitektur nach Anspruch 
1 Oder 2, dadurch gekennzeichnet, daB die Fem- 
steuerung nach dem OLE-Automation Standard er- 
folgt 

4. Medizinische Systemarchitektur nach einem der 
Anspniche 1 bis 3, dadurch gekennzeichnet dafi 




10 



der Femsteuerbaustein ein Automation Interface 
Baustein (19, 22, 27 bis 31) ist 

5. Medizinische Systemarchitektur nach Anspruch 15 
1, dadurch gekennzeichnet, daB die Femsteuerung 
mit Software- IC-Verbindungen (35 bis 41) erfolgt 

6. Medizinische Systemarchitektur nach Anspruch 
1 Oder 5, dadurch gekennzeichnet, daB die Fem- 
steuerung nach dem ATOMIC-Standard erfolgt 20 

7. Medizinische Systemarchitektur nach Anspruch 
5 Oder 6, dadurch gekennzeichnet daB der Fem- 
steuerbaustein ein Connectable/Remote Interface 
Baustein (35 bis 41) ist 

8. Medizinische Systemarchitektur nach einem der 25 
Anspruche 1 bis 7, dadurch gekennzeichnet daB 
das Verfahren zum Datenaustausch der Microsoft- 
standard OLE ist 

9. Medizinische Systemarchitektur nach einem der 
Anspruche 1 bis 8, dadurch gekennzeichnet daB 30 
der Standard fur OLE Custom Controls der Micro- 
softstandard OCX ist 

10. Medizinische Systemarchitektur nach einem der 
Anspniche 1 bis 9, gekennzeichnet durch die Ver- 
wendung von Microsoft OCX zur Erstellung von 35 
Komponenten fur grafische Benutzeroberflachen 
Innerhalb eines ProzeB-Microsoft Containers. 

1 1. Medizmische Systemarchitektur nach einem der 
Anspruche 1 bis 10, gekennzeichnet durch die 
Kombination von Microsoft OCX mit OLE-Auto- 40 
mation zur verteilten Ausbreitung eines Ereignis- 
ses mit der Kontrollebene und zwischen der Kon- 
trollebene und der Serviceebene. 

12. Medizinische Systemarchitektur nach einem der 
Anspruche 1 bis 11, gekennzeichnet durch die 45 
Kombination von Microsoft OCX mit Software-IC- 
Verbindungen zur verteilten Ausbreitung eines Er- 
eignisses mit der Kontrollebene und zwischen der 
Kontrollebene und der Serviceebene. 
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